Activity: Establish CM Policies

Purpose CM policies are used to monitor and safeguard project assets, and to enforce software development practices. Project policies should improve communication amongst the team members and minimize problems encountered when integrating their work.
Steps Define Configuration Identification Practices Define Baselining Practices Define Archiving Practices Define Configuration Status Reporting Requirements
Input Artifacts: Software Development Plan (SDP) Configuration Management Plan	Resulting Artifacts: Configuration Management Plan
Frequency: CM practices described in this activity need to be established by the beginning of the Elaboration Phase following project approval, and then re-visited through the project lifecycle at the beginning of the Construction and Transition Phases.
Worker: Configuration Manager
Tool Mentors: Creating Baselines using Rational ClearCase« Baselining Requirements using Rational RequisitePro« Viewing the History of a Defect Using Rational ClearQuest« Setting Up Policies Using Rational ClearCase

Workflow Details:

Core Workflow: Configuration & Change Management

Plan Project Configuration & Change Control

Define Configuration Identification Practices

Configuration identification is a core piece of configuration management and is defined by the IEEE as "an element of configuration management, consisting of selecting the configuration items for a system and recording their functional and physical characteristics in technical documentation". In terms of software configuration management, configuration identification means being able to find and identify the correct version of any project artifact quickly and easily. The negative impact of having an ineffective configuration identification system is measured in terms of lost time and quality.

Labels identify specific versions of artifacts. The set of artifacts that constitute a version of a subsystem are, collectively and individually, identifiable by a particular version and label. Labels are therefore useful in re-use or referencing original sets of versioned artifacts.

The following is a suggested product artifact labeling convention that can be used for labeling paths and artifacts in the Product Directory Structure.

Define Baselining Practices

A baseline provides a stable point, and a snapshot of the project artifacts. Concepts: Baselining describe when in the project lifecycle baselines need to be created. This step provides further guidance on the practice.

Baselines identify fixed sets of versions of files and directories and are created at given project milestones. Baselines can be created for a subsystem, or for the entire system. Baselines should be identified in accordance with the scheme outlined in the preceding process step (Define the Artifact Labeling Convention).

One distinction that needs to be made at the time of creating a baseline are whether you will be creating:

As a general guideline, it would facilitate release management to create System Baselines at the major and minor project milestones, and Subsystem Baselines as required or at a higher frequency. As a ærule of thumbÆ it is a good idea to create a baseline if up 30% of the components in a subsystem have been changed.

Define Archiving Practices

The purpose of this step is to ensure that project software and related assets (master documents) are backed-up, catalogued and transferred to designated storage sites. Archives show their value in times of re-use or disaster. As such, archives need to be done regularly and at major and minor milestones.

Labeling guidelines described earlier under the process step æDefine the Artifact Labeling ConventionÆ can be used when creating archiving labels. However, additional information may be required on where the actual media is to be stored. For example:

All product related information should be maintained on a database to facilitate release and re-use.

Define Configuration Status Reporting Requirements

Purpose

Change activity is a powerful indicator of project status and trends. The purpose of this process step is for the Project Manager to define what product related change data is to be reported, by whom and at what frequency.

Substeps:

Select Change Request Based Reports
Define Reporting Frequency

Tool Mentors:

Select Change Request Based Reports

Here, you should select reports that can be derived from the Change Requests submitted to the project. There are a number of useful Change Request based reports.

Under the æagingÆ category, reporting could be requested in terms of the number of Change Requests over time periods of a week or month based on the following criteria:

Listing problems by state can help determine how close to completion the project might be. For example, if the bulk of the problems have been resolved then completion is closer than if the bulk of the problems are in the submitted state.

Under the ædistributionÆ category, reporting could be requested to answer the following types of questions:

These metrics can help in the analysis of work load, who is working on the most critical problems, and how quickly the problems are being closed.

Under the ætrendÆ category, reports could be requested to answer the following types of questions:

This data is useful assessing repair rates and could provide indications of engineering efficiency.

Define Reporting Frequency

Ensure that reports are received at the right frequency to be provide meaningful input for decision making. Reports could be requested on the following basis: